iT邦幫忙

2026 iThome 鐵人賽

DAY 5
0
Vibe Coding

從零打造 AI 專題:給非本科生的工具實作與 Vibe Coding 指南系列 第 5

Day 5|別再用「我覺得」做專題:用 AI 設計訪談與問卷,驗證真實需求

  • 分享至 

  • xImage
  •  

前四天,我們已經完成:

  • 從真實問題開始發想專題
  • 查證 AI 找到的資料
  • 將模糊需求寫成可驗收的提示詞
  • 建立能追溯來源的專題知識庫

然而,到目前為止,我們仍可能只是在證明:

我們找到很多和這個問題有關的資料。

這不代表目標使用者真的會遇到相同問題,更不代表他們需要我們準備開發的功能。

例如,團隊想做「校園剩食媒合助手」,有人可能會說:

我覺得學生應該很需要便宜餐點。

這句話可能合理,但仍然只是團隊的假設。

我們還不知道:

  • 學生通常在什麼情況下找不到餐點?
  • 問題一週發生幾次?
  • 他們目前怎麼解決?
  • 現有方法哪裡不方便?
  • 問題嚴重到值得改變行為嗎?
  • 餐廳是否願意提供即時資訊?
  • 使用者真正需要的是媒合、提醒、地圖,還是營業資訊?

今天要學習如何利用 AI 協助設計訪談、整理證據及建立問卷,但真正的答案必須來自真實使用者。


AI 可以模擬回答,卻不能替你驗證需求

我們可以要求 AI:

請模擬一位晚上留校的大學生,說明找晚餐時遇到的問題。

AI 確實能產生一段合理的回答,但這只能用來幫助團隊預想情境,不能當成使用者研究證據。

原因很簡單:

  1. AI 不是你真正的目標使用者。
  2. AI 不知道你們校園的實際環境。
  3. AI 可能根據常見模式,產生看似合理但未曾發生的故事。
  4. AI 不會因為回答錯誤,而承受真正的使用成本。

因此,AI 在使用者研究中的定位應該是:

AI 適合協助 仍需由人負責
產生訪談問題初稿 尋找真正的受訪者
檢查誘導式問題 取得訪談與錄音同意
整理匿名逐字稿 確認逐字稿是否正確
將回答初步分類 判斷分類是否符合原意
找出重複主題 保留矛盾與少數意見
協助設計問卷 決定研究對象及發放方式
計算及呈現結果 判斷證據是否足以做決策

一句話總結:

AI 可以協助處理研究資料,但不能替團隊創造研究證據。


訪談和問卷不是同一件事

初學者常在還不了解問題時,立刻製作一份 Google 表單,然後詢問:

如果有一個 AI 剩食媒合平台,你會使用嗎?

即使有 80% 的人回答「會」,我們仍不知道他們是不是真的遇過問題,也不知道他們是否真的會改變行為。

訪談和問卷適合回答不同問題:

方法 主要目的 適合提問 使用時機
訪談 發現原因、行為與情境 為什麼、上次怎麼做、遇到什麼困難 專題初期
問卷 檢查頻率、比例及族群差異 多常發生、有多少人、哪個選項較常見 已有初步發現後
原型測試 檢查解法是否可用 能否完成任務、在哪一步卡住 做出原型後

今天採用的順序是:

  1. 寫下問題假設
  2. 訪談真實使用者
  3. 整理行為與證據
  4. 寫出使用者需求
  5. 用小型問卷檢查初步發現
  6. 決定 MVP 要做、修改或停止

https://ithelp.ithome.com.tw/upload/images/20260919/20184348wleXxbARCb.png

圖 1:從假設到 MVP 決策的需求驗證流程。先透過訪談取得真實事件,再進行證據編碼與需求整理,最後以問卷檢查初步發現;證據不足時回到訪談,而不是直接開發。製作方式:依據 GOV.UK 使用者研究指南及 Google Forms 官方文件自行繪製 SVG,再輸出為 1800×1100 PNG。

圖片替代文字:

從問題假設、使用者訪談、證據編碼、需求陳述、問卷檢查到 MVP 決策的六步循環,證據不足時會返回繼續研究。


第一步:先寫「假設卡」,不要急著寫功能

進行訪談前,先把團隊的想法明確寫成假設。

可以使用以下格式:

【目標使用者】
晚上六點後仍留在學校的學生

【發生情境】
下課、開會或社團活動結束後,臨時尋找晚餐

【我們認為的問題】
學生不知道哪些店家仍在營業,也不知道是否還有餐點

【目前可能的做法】
詢問朋友、查看地圖、逐間走訪或直接去便利商店

【可能造成的影響】
花費較多時間、選擇變少或放棄購買正餐

【尚未確認】
1. 問題發生頻率
2. 使用者最在意時間、價格還是距離
3. 現有地圖工具為什麼不夠用
4. 學生是否需要剩食資訊
5. 店家是否願意更新餐點狀態

這張卡不是結論,而是一份等待被推翻或修正的假設。

訪談的目的不是證明團隊是對的,而是確認:

真實使用者的生活,和我們想像的一不一樣?


第二步:找對受訪者,而不是只找支持你的人

假設專題的目標使用者是「晚上留校的學生」,受訪者就應該真的有相關經驗。

不適合的招募方式:

  • 只訪問同一組的組員
  • 只找知道專題內容的朋友
  • 只找本來就支持你的人
  • 訪問從不在晚上留校的人
  • 要受訪者想像完全沒有經歷過的情境

第一輪不需要追求非常大的樣本,可以先訪談 5 位條件不同但符合情境的使用者,例如:

  • 經常參加社團的學生
  • 晚上有實驗課或專題會議的學生
  • 住校生
  • 通勤生
  • 有飲食限制的學生

5 位受訪者不能代表全校,但足以幫助團隊發現:

  • 原本沒有想到的情境
  • 重複出現的問題
  • 使用者目前的替代方法
  • 不同使用者之間的矛盾
  • 下一輪需要追問的方向

如果訪談結果差異很大,不應強迫把它們合併成同一種需求,而是要考慮是否存在不同使用者族群。


第三步:讓 AI 產生訪談初稿,再人工刪除誘導問題

可以把假設卡交給 AI,使用以下提示詞:

你是一位協助大學生進行使用者研究的教練。

【專題假設】
目標使用者:晚上六點後仍留在學校的學生
情境:下課或社團結束後臨時尋找晚餐
假設問題:學生不知道哪些店家仍在營業,也不知道是否還有餐點
可能解法:校園餐點資訊或剩食媒合服務

【任務】
請設計一份 15 分鐘的半結構式訪談大綱。

【要求】
1. 訪談目的是了解過去的真實行為,不是推銷解法。
2. 先詢問最近一次發生的具體事件。
3. 詢問目前做法、遇到的困難、造成的影響及替代方案。
4. 不要先提到 App、AI、剩食媒合或我們準備的功能。
5. 避免「你是不是」「你會不會喜歡」等誘導問法。
6. 每一題只詢問一件事。
7. 為每個主問題提供 1~2 個中立追問。
8. 最後說明每一題希望驗證的假設。

請以表格輸出:
- 順序
- 主問題
- 可用追問
- 想了解的資訊
- 可能的誘導風險

AI 產生問題後,不要直接拿去訪談。再執行一次「反向檢查」:

請檢查上一份訪談大綱,找出:

1. 暗示受訪者應該同意的問題
2. 一次詢問兩件事的問題
3. 要求受訪者預測未來行為的問題
4. 過早提到解決方案的問題
5. 可能讓受訪者感到壓力的問題
6. 無法取得具體證據的抽象問題

請逐題說明風險,並改寫成中立、可詢問過去真實經驗的版本。

不好的問題與比較好的改寫

誘導式問題

不建議:

你是不是覺得學校晚上很難買到便宜的餐點?

這句話已經暗示「很難」及「便宜很重要」。

可以改成:

請回想最近一次晚上留在學校並尋找餐點的經驗,當時發生了什麼?

追問:

你先做了什麼?後來又做了什麼?


預測未來行為

不建議:

如果我們做一個 AI 剩食平台,你會使用嗎?

受訪者可能只是出於禮貌回答「會」。

可以改成:

上一次遇到這個情況時,你最後使用了什麼方法?

追問:

為什麼選擇這個方法?有沒有放棄過其他選項?


一次問兩件事

不建議:

你覺得找餐廳和比較價格方便嗎?

受訪者可能覺得找餐廳方便,但比較價格不方便。

應拆成:

上次尋找仍在營業的餐廳時,你用了什麼方法?

以及:

當時有比較不同餐點的價格嗎?你怎麼比較?


過度抽象

不建議:

你對校園餐飲數位轉型有什麼看法?

可以改成:

最近一次在校園使用手機尋找餐點資訊是什麼時候?你查看了哪些資訊?

具體事件通常比一般意見更接近真實行為。


第四步:進行訪談,讓受訪者多說一點

一場 15 分鐘的訪談可以分成:

階段 時間 內容
說明與同意 2 分鐘 說明目的、資料用途及是否錄音
暖身 2 分鐘 了解受訪者與問題情境
最近一次事件 6 分鐘 依照時間順序還原真實經驗
困難與影響 3 分鐘 了解卡點、替代方案及結果
結尾 2 分鐘 詢問遺漏事項及是否可再次聯絡

開場可以使用:

我們正在了解學生晚上留校時尋找餐點的經驗,不是在測驗你,也沒有標準答案。

訪談內容只用於課程專題分析。我們會移除姓名與可辨識身分的資訊。

請問你是否同意我們做文字紀錄?
如果希望錄音,我們會另外徵求你的同意。你可以拒絕回答任何問題,也可以隨時停止訪談。

訪談時應注意:

  • 不要急著介紹你們的解法
  • 不要替受訪者完成句子
  • 遇到模糊說法時,詢問具體例子
  • 受訪者停頓時,不必立刻換題
  • 記錄原話,不要只記自己的解讀
  • 注意「實際做了什麼」和「認為應該怎麼做」的差異

一個很好用的追問是:

可以帶我回到那一次,從事情開始時說起嗎?


第五步:匿名化之後,再請 AI 協助整理訪談

不要直接把含有姓名、學號、電話或其他個資的逐字稿貼入 AI 工具。

建議先將受訪者代碼化:

P01:住校生,每週約有三天晚上留校
P02:通勤生,參加社團後才會晚上留校
P03:有素食需求的學生

確認逐字稿後,可以使用以下提示詞進行初步編碼:

以下是已匿名化的使用者訪談逐字稿。

【任務】
請只根據逐字稿中的內容建立「訪談證據表」。

【欄位】
1. 受訪者代碼
2. 原文引句
3. 發生情境
4. 實際行為
5. 遇到的困難
6. 現有替代方法
7. 造成的影響
8. 可能的需求
9. 不確定或需要追問之處

【規則】
- 不可創造逐字稿中沒有出現的行為或動機。
- 「可能的需求」必須與原文引句對應。
- 如果證據不足,標示「無法判斷」。
- 保留不同受訪者之間互相矛盾的內容。
- 不要因為多數人提到某件事,就刪除少數人的重要情境。

例如:

原文證據 行為 困難 可能需求
「七點下課後,我會先看地圖,但上面寫營業,走過去卻關了。」 使用地圖查找餐廳 營業資訊不即時 需要可信的即時營業狀態
「我通常直接去便利商店,因為不想花時間找。」 放棄比較其他選項 尋找成本過高 需要快速縮小選擇範圍
「我吃素,很多店雖然開著,但我不能吃。」 逐間查看菜單 缺少飲食條件資訊 需要依飲食限制篩選

這張表中的「可能需求」仍然是研究者的整理,不是不可修改的事實。

團隊應該回到原始逐字稿,確認 AI 沒有:

  • 誤解受訪者語氣
  • 省略前後文
  • 將猜測寫成事實
  • 把兩位受訪者的經驗合併
  • 把「偶爾」改成「經常」

第六步:將證據寫成需求,而不是直接寫功能

GOV.UK 的使用者研究指南強調,好的使用者需求應以研究證據為基礎,聚焦使用者想完成的事情,而不是預先指定某一種解法。

可以使用以下格式:

作為【哪一類使用者】,
當【發生什麼情境】時,
我需要【完成什麼事情】,
以便【得到什麼結果】。

證據:
【受訪者代碼及原文摘要】

限制:
【目前樣本與未知事項】

例如:

作為晚上留校的學生,
當我臨時需要尋找晚餐時,
我需要快速確認附近仍在營業且符合飲食條件的餐點,
以便不用逐間前往確認。

證據:
P01、P02 提到地圖營業資訊不準確;
P03 提到無法直接辨識素食選項。

限制:
目前只有 5 位受訪者,且多數來自同一個校區。

避免把需求寫成:

使用者需要一個結合 AI、地圖及推播功能的剩食 App。

這已經是解法,不是需求。

如果太早將需求和特定功能綁在一起,團隊可能會忽略更簡單的方案,例如:

  • 即時營業資訊頁
  • 店家共用表單
  • LINE 機器人
  • 定時更新的校園餐點地圖
  • 不需要 AI 的篩選功能

AI 專題不是使用越多 AI 越好,而是要把 AI 放在真正需要判斷、整理、推薦或生成的環節。


第七步:有訪談發現後,再建立小型問卷

訪談告訴我們「可能發生什麼」,問卷則用來初步檢查:

  • 問題發生的頻率
  • 哪些族群比較常遇到
  • 哪一項困難最普遍
  • 目前最常使用的替代方案
  • 哪個需求值得優先處理

Google Forms 提供簡答、段落、單選、核取方塊、線性刻度等題型,也能將回覆連結到 Google Sheets 或下載成 CSV。

一份初步需求問卷可以控制在 5~8 題:

1. 過去四週,你有幾天在晚上六點後仍留在學校?
   - 0 天
   - 1~2 天
   - 3~5 天
   - 6 天以上

2. 最近一次晚上留校並尋找餐點時,你最後如何處理?
   - 前往原本熟悉的店家
   - 使用地圖搜尋
   - 詢問朋友
   - 前往便利商店
   - 使用外送平台
   - 沒有購買餐點
   - 其他:___

3. 那次經驗中,你遇到哪些情況?(可複選)
   - 不知道店家是否營業
   - 到店後發現已售完
   - 找不到符合預算的餐點
   - 找不到符合飲食需求的餐點
   - 距離太遠
   - 等待時間太長
   - 沒有遇到問題
   - 其他:___

4. 這類情況在過去四週發生幾次?
   - 0 次
   - 1 次
   - 2~3 次
   - 4 次以上
   - 不確定

5. 如果只能改善一項資訊,你最希望優先確認什麼?
   - 是否營業
   - 是否還有餐點
   - 價格
   - 距離
   - 等待時間
   - 飲食分類
   - 其他:___

6. 是否願意接受一次 10 分鐘的後續訪談?
   - 願意
   - 暫時不願意

如果需要聯絡願意接受後續訪談的人,可以另外建立聯絡表單,不要讓姓名或電子郵件和主要研究回答不必要地綁在一起。


讓 AI 檢查問卷品質

問卷完成後,可以把題目交給 AI 檢查:

請以使用者研究方法顧問的角度,檢查以下問卷。

請逐題檢查:
1. 是否一次詢問兩個概念
2. 是否暗示某個答案比較正確
3. 選項是否重疊
4. 選項是否遺漏常見情況
5. 時間範圍是否明確
6. 受訪者是否有能力準確回答
7. 是否蒐集了不必要的個人資料
8. 回答結果能否支持專題決策

請使用表格輸出:
- 題號
- 問題
- 風險
- 修改建議
- 這題能支持的決策

不要替我虛構調查結果。

注意,AI 可以檢查問卷文字,但不能保證問卷一定有效。

正式發放前,先找 2~3 位同學試填,觀察:

  • 他們是否看得懂題目
  • 選項是否找得到適合答案
  • 是否誤解時間範圍
  • 填寫時間是否太長
  • 是否有題目讓人不舒服
  • 回覆能否真的支持專題決策

這個步驟稱為預試。五分鐘的預試,可能避免收到一百份無法解讀的回答。


收資料前,先決定「看到什麼結果要怎麼做」

如果收完資料才設定標準,團隊很容易只挑選支持原本想法的結果。

可以事先設定專題決策門檻:

【進入 MVP 的條件】
1. 5 位訪談者中,至少 3 位曾在最近一個月遇到相似問題。
2. 問題有具體行為或後果,而不只是一般抱怨。
3. 至少存在一種目前的替代方法,代表使用者正在付出成本解決。
4. 小型問卷中,目標族群的回答足以顯示問題值得繼續研究。
5. 團隊可以在競賽時程內做出可操作的解法。

【需要修改方向】
- 問題存在,但只集中在特定使用者。
- 使用者真正重視的項目和原假設不同。
- 現有工具已能有效解決大部分情況。

【考慮停止】
- 找不到最近發生的真實事件。
- 使用者沒有任何解決動機。
- 問題影響極低。
- 解法需要無法取得的資料或合作對象。

這些數字只是團隊用來篩選方向的專題門檻,不代表統計學上的全校結論。

例如,30 份便利取樣問卷不能證明「全校有 60% 的學生需要這項服務」。比較準確的說法是:

在本次取得的 30 份有效回覆中,有 18 位曾遇到相關情況;由於樣本主要來自社團學生,結果仍需擴大到其他族群驗證。

評審通常不會因為樣本不大就否定學生專題,但會在意團隊是否誠實說明限制。


常見錯誤一:把訪談變成產品推銷

如果前五分鐘都在介紹功能,受訪者後面的回答就可能受到影響。

先談過去經驗,再談可能的解法。


常見錯誤二:只問「你會不會用」

人們對未來行為的預測不一定準確。

比起「你會使用嗎」,應優先詢問:

  • 最近一次是什麼時候?
  • 當時做了什麼?
  • 花了多少時間?
  • 最後怎麼解決?
  • 為什麼放棄其他方法?

常見錯誤三:把 AI 模擬訪談當成正式資料

AI 模擬適合用來:

  • 練習訪談技巧
  • 預想可能出現的答案
  • 測試追問是否自然
  • 找出訪談大綱的漏洞

但不能寫進成果報告:

我們訪談了 20 位 AI 模擬使用者。

競賽需要的是真實世界證據。


常見錯誤四:只留下多數意見

假設四位受訪者都能使用一般餐點資訊,但一位受訪者有食物過敏需求。

這個少數意見不一定應被刪除,因為它可能代表:

  • 高風險情境
  • 無障礙需求
  • 被現有服務忽略的族群
  • 值得另外設計的使用者分群

應記錄差異,而不是讓 AI 把所有回答平均化。


常見錯誤五:問卷收很多,卻無法支持決策

以下題目看起來有趣,但很難指導 MVP:

你覺得 AI 很重要嗎?

比較有用的問題是:

最近一次遇到此問題時,你使用什麼方式處理?

每一道問題都應該能回答:

如果結果是 A 或 B,團隊會做出什麼不同決定?

如果不會影響任何決策,就考慮刪除。


今日成果驗收表

驗收項目 合格標準
假設清楚 已寫出使用者、情境、問題及未知事項
對象正確 受訪者真的有相關經驗
問題中立 沒有先介紹產品或暗示正確答案
行為具體 至少取得一個最近發生的真實事件
證據可追溯 每項需求能回到匿名引句或紀錄
保留差異 沒有刪除矛盾或少數意見
個資最少化 已移除不必要的姓名、學號及聯絡資訊
AI 未造假 沒有把模擬回答寫成真人證據
問卷有目的 每一題都能支持一項專題決策
限制透明 已註明樣本來源及不能推論的範圍
決策明確 能決定繼續、修改或停止

通過這張表,才算完成初步需求驗證。


今天的實作練習

請以目前的 AI 專題方向完成以下任務。

任務一:完成一張假設卡

至少包含:

  • 目標使用者
  • 發生情境
  • 假設問題
  • 現有做法
  • 可能影響
  • 五項未知事項

任務二:訪談三位真實使用者

每位訪談 10~15 分鐘,並取得紀錄同意。

至少詢問:

  • 最近一次相關事件
  • 實際行為
  • 遇到的困難
  • 現有替代方法
  • 最後結果

任務三:整理十筆證據

每筆包含:

  • 匿名受訪者代碼
  • 原文引句
  • 行為
  • 困難
  • 影響
  • 不確定事項

任務四:寫出一項需求陳述

作為____,
當____時,
我需要____,
以便____。

證據:____
限制:____

任務五:製作五題小型問卷

每一題旁邊寫下:

這題的結果會影響哪一項專題決策?

如果回答不出來,就刪除或修改題目。


今日重點

今天最重要的不是完成一份漂亮問卷,而是建立這條證據鏈:

團隊假設
→ 真人過去經驗
→ 可追溯的原文證據
→ 使用者需求
→ 問卷初步檢查
→ MVP 決策

AI 可以協助產生問題、檢查偏誤、整理逐字稿與比較結果,但不能替代:

  • 真實使用者
  • 訪談同意
  • 原始證據
  • 人工查核
  • 團隊決策

能得獎的專題不一定使用最多工具,但通常能清楚回答:

你們怎麼知道這是真正的問題?


下一篇預告

Day 6,我們會把今天確認的使用者需求轉換成 User Story、功能優先順序及 MVP 範圍,避免專題變成「什麼都想做,最後什麼都做不完」。


官方參考資料

  1. GOV.UK Service Manual|Learning about users and their needs
  2. Google Docs Editors Help|Choose a type of question for your form
  3. Google Docs Editors Help|View & manage form responses

以上官方資料於 2026 年 9 月 19 日查閱。Google Forms 的介面、題型與回覆管理功能可能更新,實際操作請以官方最新說明為準。


上一篇
Day 4|資料不要再散落各處:用 NotebookLM 建立可追溯的 AI 專題知識庫
下一篇
Day 6|功能越多越容易失敗:用 User Story 與優先級切出做得完的 MVP
系列文
從零打造 AI 專題:給非本科生的工具實作與 Vibe Coding 指南6
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言